1. Field of the Invention
The present invention relates in general to computer programs, and more particularly to an automatic activation and configuration of a debugger.
2. Description of the Related Art
Conventional systems provide numerous ways of invoking a debugger. A user may manually invoke a debugger by entering a command on a command line or by selecting an icon representing the debugger in a graphical user interface. Alternatively, the user may automate the invocation of the debugger by the use of various flags, control statements, or calling statements.
Crump et al., U.S. Pat. No. 5,850,562, “Personal Computer Apparatus and Method for Monitoring Memory Locations States for Facilitating Debugging of Post and BIOS Code,” and Nelin et al., U.S. Pat. No. 6,253,368, “Dynamically Debugging User-Defined Functions and Stored Procedures” teach the use of flags to invoke a debugger. In Crump et al., a flag is checked when a system is initialized, and if the flag is set, then a default debugger is invoked. Nelin et al. provides improved use of a flag wherein the flag indicates that a default debugger is invoked when a particular program is executed.
The use of control statements may provide greater control and function. For example, Tomlinson, Paula “Debugging Services (Understanding NT) (Technology Tutorial)”, Windows Developer's Journal, Number 8, Volume 7, August, 1996, page 55, teaches an improvement beyond the system initialization flag wherein a system initialization control statement invokes both a specified program and a specified debugger with which to debug the program. Carney et al., U.S. Pat. No. 5,774,729, “Event Handling in a High Level Programming Language Environment” extends such control statement teachings beyond system initialization to the initialization of an individual program wherein a control statement which invokes the program may also invoke a specified debugger with which to debug the program.
Instead of a control statement external to the program, Yoshio, JP61016344A2, “Conversational Debugging Processing System” teaches the use of a calling statement within the program to be debugged that invokes a specified debugger with which to debug the program. Fuh et al., U.S. Pat. No. 6,324,683, “System, Method and Program for Debugging External Programs in Client/Server-Based Relational Database Management Systems” teaches the use of such a calling statement within a segment of code inserted before the program to be debugged.
Rather than associating the debugger with a particular program, Hawley et al., U.S. Pat. No. 5,533,192, “Computer Program Debugging System and Method” teaches associating the debugger with a particular type of exception or interrupt, thus invoking a specified debugger when a specified type of exception or interrupt occurs. Other exception handlers, condition handlers, or event handlers which do not invoke a debugger, but instead use an already executing debugger are taught by Conder et al., U.S. Pat. No. 5,724,564, “Computer Program Product and Program Storage Device for Representing and Signaling Run-Time Program Conditions”; Carney et al., U.S. Pat. No. 5,630,137, “Condition Handling in a Multi-Language Computer Program”; Conder et al., U.S. Pat. No. 5,455,949, “Method for Representing and Signaling Run-Time Program Conditions”; and Ault et al., U.S. Pat. No. 5,632,032, “Cross Address Space Thread Control in a Multithreaded Environment”.
These conventional ways of invoking a debugger suffer significant limitations and disadvantages. The use of flags which may invoke the debugger before the program or event of interest may cause significant unnecessary overhead associated with the execution of the debugger incurred during the time before the program or event of interest. The resolution of the meaning of the flags is also limited. The flags may only indicate a default debugger, not a selection of a particular debugger, and not the configurable parameters of a particular debugger. The flags may only indicate a particular program, not events within the program.
Control statements also share these limitations as control statements may invoke the debugger before the program or event of interest causing significant unnecessary overhead associated with the execution of the debugger incurred during the time before the program or event of interest. Although the control statement resolution is greatly improved over that of the debugger flags in that they may specify a particular debugger instead of just the default debugger, the control statements still may only indicate a particular program, not events within the program.
Finally, the exception handlers may fail to reduce the overhead associated with the execution of the debugger incurred during the time before the event of interest in the program of interest. Although an exception handler may invoke a specific debugger for a particular type of exception or interrupt, it may invoke the debugger for every exception or interrupt of this type, not just the particular exception or interrupt of interest, thus resulting in significant debugger overhead. It may also invoke the debugger for every exception or interrupt of this type, even if the exception or interrupt occurs outside of the program of interest. Significant debugger overhead may be incurred if the event of interest is not an exception or interrupt as the debugger may be invoked by events other than the event of interest in order to monitor the event of interest. The exception handler may also fail to configure the debugger invocation with the appropriate debugger options or parameters.
Thus, there is a clearly felt need for improved debugging in which a user may specify a particular event within a particular program which causes a specified debugger to be invoked with specified debugger options.